Software Requirements Specification

Siena College Catalog Project

November 2, 2004

Requested by: Ms. Kate Zimmerman

Academic Program Administrator

Office of Academic Affairs

Siena College

Mr. Brian Smith

College Webmaster

Office of Enrollment and Planning Technology

Siena College

Ms. Lisa Veino

Office of Academic Affairs

Spartacus Computing Solutions

Prepared by: Michael Cervone, Web Designer

Thomas Hackett, Librarian

Sean Hannon, Software Consultant

Sara Pagliaro, Team Leader

John Sawicki, Systems Administrator

E-mail: spartacus_computing@hotmail.com

Presentation information: Wednesday, November 3, 2004

Roger Bacon 328

8:15 AM

Siena College Catalog Database

Software Requirements Specification

Table of Contents

Software Requirements Specification

Section 1: Product Overview and Summary………………………………………….. 3

Section 2: Development, Operating, and Maintenance Environments……………….. 3

Section 3: External Interfaces and Data Flows……………………………………….. 4

Section 4: Functional Requirements………………………………………………….. 4

Section 5: Performance Requirements………………………………………………... 5

Section 6: Exception Handling……………………………………………………….. 5

Section 7: Early Subsets and Implementation Priorities……………………………… 6

Section 8: Foreseeable Modifications and Enhancements……………………………. 6

Section 9: Acceptance Criteria……………………………………………………….. 6

Section 10: Testing Requirements……………………………………………………. 7

Section 11: Design Hints and Guidelines…………………………………………….. 8

Appendices:

Appendix A: Data Flow Diagrams……………………………………………………. 9

Appendix B: Prototypes of External Interfaces……………………………………….. 16

Appendix C: Gantt Charts…………………………………………………………….. 25

Appendix D: Glossary of Terms…………………………………………………….... 26

Section 1: Product Overview and Summary

The process of editing and reproducing the Siena College Catalog has been a tedious paper-pushing process in the past. Ms. Kate Zimmerman and Mr. Brian Smith have asked Spartacus Computing Solutions to transform this process so that it can be done electronically. The information for the catalog will be stored in a database. The various department heads, assistant deans, vice presidents, and other specified users will have access to the most recent version of the catalog in order to make changes limited to their fields. Updates to the database will be done in real-time so that the users in Academic Affairs can compare the old version with the updated version.

Section 2: Development, Operating and Maintenance Environments

The Siena College Course Catalog program will be developed on systems provided to us in the software engineering lab. The computer resources consist of a machine with Windows 2000 and another with Windows XP. For development purposes we will be using mySQL, as per the request of our clients, for the newly created course catalog database. The mySQL course catalog database will also be populated with some data from the Siena database “Banner.” Data from Banner will include such information as course description, department descriptions, and department faculty listings. The web interface of the program will be developed with PHP and/or ASP, as per the request of our clients.

The user interfaces will consist of a variety of screens depending on the person using the screen and what they are responsible for doing, described as follows:

The department heads will have a screen that allows them to review the faculty information, department information, read the course descriptions, and a field to make notes as to what changes they have made. The department head can modify the faculty and department information, but the course description is to be “Read Only” access. The data fields will contain verification that the department head has looked at and acknowledged that the fields are ready for the catalog.

The College Administrators will also have a screen from which they will be able to make changes to the general information (i.e. mission statements, school information, etc.) They will be able to make changes to this information and record the changes that they made. They will then have a field where they can verify that the field that they edited is ready for the catalog.

The Assistant Deans and Deans will have a screen that allows them to view the progress made by the department heads underneath them in terms of verifying the data fields which they are responsible for. The Assistant Dean will also be able to review a summary of changes made by the department heads.

Academic Affairs will have an environment much like that of the Assistant Dean with a few exceptions. A list of all department heads will be visible and will show the progress that they have made. Also, a summary of changes will be available for viewing and editing (if necessary) by Academic Affairs. Academic Affairs will also have a maintenance environment which they will be able to grant permissions to different users, which will determine what screens and information other users will be able to access.

Universal users will also have a screen which they will have access to the electronic catalog for viewing purposes only. They will not be able to make any changes, but will be able to select the course or part of the catalog that they want to view.

Section 3: External Interfaces and Data Flows

Data flow diagrams are located in Appendix A. Prototypes for the external interfaces are located in Appendix B.

Section 4: Functional Requirements

The following functions are required for our system:

• The system will have a login screen for all authorized users, including department heads, school deans and assistant deans, college administrators, and members of the Academic Affairs staff.
• The system will have an authentication process to restrict unauthorized people.
• Department heads, school deans and assistant deans, college administrators, and the database administrator in Academic Affairs will allow have the ability to make changes to specified portions of the database. Department heads and college administrators can only modify information in their departments, while users at the dean level may modify information in any department that it oversees. The head user at the Academic Affairs level (i.e., Ms Zimmerman) will be able to modify any changes to any department’s information.
• Users at the dean level will have the ability to approve changes made in sections from those at the department head level.
• Users will receive confirmation that their request was received.
• The head user from Academic Affairs (i.e., Ms. Zimmerman) with have administrative privileges and in turn, will have the ability to:
• Create new users
• Set or reset user passwords
• Grant users proper access to the system
• Remove or limit access from users
• Make changes to information within the system
• Deny changes submitted by any user
• Approve final changes to the information to be stored in the catalog database
• Delete a user and his/her system privileges at anytime
• The head user must monitor and maintain the database on a consistent basis to ensure the system is running and working properly.

Section 5: Performance Requirements

In order for our College Catalog Program to perform properly, several constraints and requirements are necessary.

· Our system must be secure. Only authorized personnel can have the ability to read from and write to our database. Reading and/or writing privileges will be provided to our users from the main administrator of Academic Affairs (i.e., Ms. Zimmerman) via use of usernames and passwords. Our system must also distinguish which part of the database the user will be able to view or update. The system must prevent unauthorized users from viewing or tampering with the information stored in our database.

· Our system must be efficient. Working with databases can be difficult if one does not know what they are doing. Simple miscalculations can cause longer processing times. Our system must be able to quickly access the documents needed for each user, which in turn will allow them to make their necessary changes rapidly and with ease. By looking at the size of text files, the time they take to load, the need to scroll through screens, as well as other timing factors, we can make adjustments to these characteristics in our system to allow for more efficiency.

· Our system must be reliable. We must make sure that everyone that is supposed to have access to the database has the proper access and is able to change the information that they have the ability to change. This reliability function will be looked at during our testing phase, when we make sure that there is an ease of use on any user’s end as well as the code for the product being correct. In order to insure the ease of use, we will involve the main users (i.e., Ms. Zimmerman) in the development of the user interface.

Section 6: Exception Handling

In many instances, our users may encounter an unexpected situation. In preparation of this, our program will try to work around these situations, should they arise. Exceptions that the system must be prepared to handle are as follows:

· User forgets username/password.

Should the user forget his/her username or password, on screen information will be provided on how to re-obtain this information. This process will be secure in order to prohibit unwanted users from accessing our database.

· User experiences abnormal computer problems (i.e. computer freezes, power/connection is lost).

The user will receive a confirmation page after their document is submitted. If this page is not received, then the document was not saved to the database. Our program may also provide the ability to backup documents every couple of minutes. If power or connection is lost, the user will not lose his/her entire work. When the user logs back on he/she may be able to access fragments of what they already completed.

Section 7: Early Subsets and Implementation Priorities

In order to meet the requirements of the system, several pieces must be completed. The most important underlying pieces of the software system are:

1. A user friendly and easy to use web application for any user to access catalog information;

2. A secure system for the data to be stored and valid user login and access to the data;

3. An online database to store all the information submitted by the authorized users and data stores (Banner, department heads, deans and assistant deans, college administrators, and users in Academic Affairs);

4. A form, designed specifically for a particular type of user, which will contain the current catalog information and allow the ability to change information, and if appropriate for the user, the ability to check off on changes already made to the current catalog.

Section 8: Foreseeable Modifications and Enhancements

In the development process, new ideas for future modifications and enhancements may arise that will improve the quality of the software. Possibilities for future changes to the software are as follows:

· New screens and functions may be added to enhance the ease of use and increase user friendliness.

· Accessing changes from multiple years’ catalogs (2+ years back), allowing for comparison.

· The ability to add new courses to the database and develop new macros for those courses.

Section 9: Acceptance Criteria

This system will allow write access to specific catalog entries to authorized users. When a user logs into the system, they are directed to their specific section.

1. Department Heads:

· Are able to view the current catalog version of the course description and of the department information.

· Are able to make necessary changes to faculty listings, department policies and class descriptions for their department.

· Has a check-off under each write section to show that all changes are finished.

2. School Assistant Dean

· Scroll bar to locate a specific department

· Has the current version of the catalog displayed one side of the screen

· The changes submitted by the department head are displayed on the screen as well.

· Check-off for each part of catalog info that was changed.

· After all changes are checked, submit an approval.

3. College Administration

· The old catalog information is displayed.

· Able to write in the changes next to old information.

· Submit the changes.

4. Academic Affairs

· Scroll to the desired department.

· Able to review changes made when compared to previous catalog.

· Check off on all changes made.

· Check off that school administration has submitted changes.

· Has total authorization of system.

Furthermore, any universal user should have the ability to view, but not edit, the course catalog via the Internet.

Section 10: Testing Requirements

• Users can log in.

Volunteers will be given a default password for a given level of access in the system. After they initially log in, they should be prompted to change their password. All levels of access will be tried with “dummy access” (so that no actual information is changed), and access will be removed after testing.

• Department Heads can view the current catalog and can submit changes.

The user should be able to access the most recent catalog from the database and then submit changes over the system to the next level of authorization.

• Assistant Dean checks off the changes.

The Assistant Dean should be able to compare, on the same screen, the current catalog and the changes made by the department head, and send verification to Academic Affairs that all changes are correct and approved.

• Assistant Dean can make changes to the catalog.

This is similar to the department heads test in that the system takes the changes and sends them through the system to Academic Affairs.

• College Administration can make their changes to the catalog.

The separate administrative offices, along with senior staff, need to be able to access their specific catalog information to make the changes and submit them over the system. This is similar to the procedure for department heads and Assistant Deans use to change the catalog.

• Academic Affairs authorizes all changes.

Academic Affairs is able to review all the changes to the catalog and also can check-off that every change needed is accounted for.

• Academic Affairs can make changes to the system.

As an ability of authorizing all changes, Academic Affairs has the ability to make any of their own changes to any section of the catalog, without restriction of department or office.

• Academic Affairs has administrative rights to the system.

Make sure that this user can reset lost passwords and also can deny changes if an unauthorized user get into the system.

Section 11: Design Hints and Guidelines

Our system is going to input some of the information for the Siena College course catalog through the college database in Banner. This ensures that the most updated information is being displayed. The rest of the information will be coming from Microsoft Word document files. Other than displaying the current catalog, the system will also allow the authorized user a chance to make the necessary changes to the catalog on the same screen. Changes can be made during the year to the current year’s catalog. The system will also tell the higher-level users that changes were made and are waiting for review. These changes will be used in the next edition of the course catalog.

In the beginning of March of each school year, when the catalog is officially up for review for the next year, the most recent version of the catalog (with changes made throughout the year) will be available for departments and offices for revision. For all changes made to the catalog, the system should be able to track the hierarchy of the changes and clearly show the changes made for the next person in the revision hierarchy.

Appendix A: Data Flow Diagrams

Appendix B: Prototypes of External Interfaces

The prototypes shown in this document are prototypes of the functionality of the software. The system’s interface may not (and probably will not) look like this upon final release of the product.

The first prototype is for a general login screen. This will prompt for a username and password from all users and the system will verify if this is an authorized user.

The following screen shows the functions that a department head would have. This screen shows a read only version of the catalog and also has a text box where the department head can make changes to the information. The information they will be modifying will be faculty information and course descriptions.

The Assistant Dean (or anyone at a Dean level) has the ability to view, change, and monitor all information for the departments under the school level. The following prototype shows the ability to view the information as it is held in the current catalog.

The Assistant Dean (or anyone at a Dean level) has the ability to view, change, and monitor all information for the departments under the school level. The following prototype exhibits the functionality of changing the faculty and department information.

The Assistant Dean (or anyone at a Dean level) has the ability to view, change, and monitor all information for the departments under the school level. The following screen shows the ability to monitor the changes from the departments within a particular school.

College administrators have the ability to make changes to the information pertaining to their particular department. This function is similar to that of the department heads, although it does not have to be approved by any member of senior staff. The following is a prototype of the functions of their screen.

Academics Affairs head user (i.e., Ms. Zimmerman) has administrator control over the system. Therefore, this person has the ability to view, modify, approve, deny, and monitor any changes submitted by any other user accessing the system. The screens for them to view, modify, and approve will be similar to the abilities that an Assistant Dean has. The ability to monitor progress will also be similar to that of the Assistant Dean and the senior staff, but with the ability to view any user’s progress. The first of the following two screens shows the capability to view a department head’s progress.

This second screen for the Academic Affairs head user (i.e., Ms. Zimmerman) shows the Assistant Dean’s progress throughout the revision process of the catalog.

The one major difference with the Academic Affairs’ head user and other users is the ability to set permissions. This function will have its own screen, which will have functionality similar to the following prototype.

Appendix C: Gantt Charts

Appendix D: Glossary of Terms

Access – A relational database running under Microsoft Windows.

Browser – An application program that provides a way to look at and interact with all the information on the World Wide Web.

Code – Symbolic arrangement of data or instructions in a computer program, or a set of such instructions.

Controlled Decentralized – An organizational structure for teams, in which a team leader is defined, but all problem solving and decision-making is the responsibility of the group.

Database – An information management system used for storing and retrieving related data.

Data Store – Generic physical files that contain data necessary for the program, but which is external from the software developed.

Data flow diagram – A representation of the functional decomposition of a system.

Dreamweaver – A program used in the development of web pages.

Gantt Chart – A graphical-based, progressive timeline containing relevant dates, often used with regard to planning and tracking a project.

GUI – Graphical User Interface: A user interface based on graphics (icons, pictures, and menus) instead of text; uses a mouse as well as a keyboard as an input device.

HMTL – Hypertext Transfer Markup Language: A markup language used to structure text and multimedia documents and to set up hypertext links between documents, used extensively on the World Wide Web.

Hypertext – A computer-based text retrieval system that enables a user to access particular locations in web pages or other electronic documents by clicking on links within specific web pages or documents.

Internet – An interconnected system of networks that connects computers around the world via the TCP/IP protocol.

Java Script – A language used in the development of web pages.

Linear Sequential Model – Sometimes called the classic life cycle or the waterfall model, this model, originally developed by W.W. Royce, suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and support.

mySQL – Open-Source database software

Network – A network of data processing nodes that is interconnected for the purpose of data communication.

Open-Source – A method and philosophy for software licensing and distribution designed to encourage use and improvement of software by making the code freely available.

Oracle – A relational database management system that runs on most mainframe, micro, and personal computers.

PHP – PHP: Hypertext Preprocessor (server-side scripting language).

Process – An activity that changes or manipulates data.

Protocol – A standard procedure for regulating data transmission between computers.

Query – A data retrieval request.

Relational Database – A database system in which any database file can be a component of more than one of the database's tables.

Software – Written programs, procedures, or rules and associated documentation pertaining to the operation of a computer system and that are stored in read/write memory.

SQL – Structured Query Language: A language used in the creation and maintenance of databases.

Use Case – Set of scenarios that show a usage of the system by a certain user.

User – An individual that has signed onto a system and has been assigned a user name and password.

Username – A system created login for users.

Universal User – Any person, whether directly or indirectly involved with the system, who has the ability to perform certain functions. In the case of the Siena College Catalog Project, any universal user has the ability to view the Siena College Catalog via the Internet.

Visual Basic – A popular event-driven visual programming system from Microsoft

Corporation for Microsoft Windows.

Web-based – Uses the World Wide Web (via HTML) on the Internet to gain access to the system.